System Limits

This panel allows administrators to determine system limits that determine how different parts of the application will behave. The panel includes three sections.

• Limit Settings
• Large Query Engine Settings
• Caching Timeouts

Limit Settings

Cube Connection Timeout (in seconds) - The amount of time the application will wait for a response from the cube servers when attempting to connect to them. A setting of 0 implies an indefinite waiting time (recommended).

• Minimum=0
• Maximum=65536

Cube Query Timeout (in seconds) - The amount of time the application will wait for a response from the cube servers when a query is launched. This setting should not be set too low, as the system will timeout on very long running queries. We recommend a setting of 300 seconds (5 minutes).

• Minimum=0
• Maximum=1800

Processing Thread Timeout - The amount of time, added to the query timeout, that the server should wait before ending the entire process. This increment represents the non-cube processing of the query. We recommend 60-300 seconds.

• Minimum=1
• Maximum=1800

SilverLight Interface Timeout - The amount of time the local SilverLight client will wait for user input before logging the user out of the system. Enter 0 to disable timer.

HTML5 Interface Timeout - The amount of time the local HTML5 client will wait for user input before logging the user out of the system. Enter 0 to disable timer.

Mobile Interface Timeout - The amount of time the local Mobile client will wait for user input before logging the user out of the system. Enter 0 to disable timer.

SilverLight Total Cells - The overall grid size limit that the main client application will handle. To improve overall performance, administrators can use this parameter to prevent users from requesting enormous cell sets from the server.

• Minimum=1000
• Maximum=750000

HTML Total Cells - The overall grid size limit that the HTML5 and mobile applications will handle. To improve overall performance, administrators can use this parameter to prevent users from requesting enormous cell sets from the server.

• Minimum=500
• Maximum=5000

Small Query Limit - The switch-point in the processing engine from the "internal" processor to the Large Query Engine (LQE). The LQE is designed to handle massive data sets. The number represents the number of cells in the query that will force the processing to be handled by the LQE. The LQE takes a little longer to process, so the limit should not be set too low.

• Minimum=1000
• Maximum=15000

Rows Limit - Large queries can be identified not only by the overall set size, but also by the number of rows returned. The Rows Limit represents the total number of rows that will returned by a cell set. If the query exceeds this limit, it will not be processed. Rows Limit is used in conjunction with Silverlight Total Cells to determine the limit of a query in the application.

• Minimum=1000
• Maximum=200000

Columns Limit - Large queries can be identified not only by the overall set size, but also by the number of columns returned. Columns Limit represents the total number of columns that will returned by a cell set. If the query exceeds this limit, it will not be processed. Columns Limit is used in conjunction with Silverlight Total Cells to determine the limit of a query in the application.

• Minimum=1000
• Maximum=50000

Multi-Grid Size Limit - The largest query that the engine will produce as a multi-grid object. Multi-grids are far more intensive than flat grids. Any cell set larger than this limit will force the engine to return the flat grid instead of the multi-grid.

• Minimum=1000
• Maximum=40000

List Builder Maximum - Specifies the upper limit of data rows that can be imported using the List Builder Wizard.

Large Query Engine Settings

Memory Limit - To ensure the stability of the application, large queries are sent to the LQE (see Small Query Limit above). The LQE's memory can be limited as a percentage of the overall machine memory - in order to ensure greater stability. Once the LQE exceeds this limit, the engine will be shut down and force the user to resubmit a smaller, more focused query.

• Minimum=1
• Maximum=100

Minimum Satellite Count - Specifies the minimum number of LQE satellite processes that are pre-loaded and kept in memory by the system. Increasing this figure provides faster access to the LQE.

• Minimum=1
• Maximum=50

Caching Timeouts

Caching eliminates repetitive reloading and re-rendering of content by storing results in memory for a specified amount of time. It generally makes the system far more responsive, especially in high volume, high concurrency rollouts.

Metadata Cache Timeout (seconds) - Specifies the number of seconds that metadata can remain in server cache without being removed. Subsequently accessing the metadata will cause the server to reload the metadata from the cube.

Content Cache Timeout (seconds) - Specifies the number of seconds that BI Office content can remain in server cache without being removed. Subsequently accessing the content will cause the server to reload the content from the content server. (Enter 0 to turn off Content Cache.)

Query Cache Timeout (seconds) - Specifies the number of seconds that a query can remain in server cache without being removed. Subsequently accessing the query will cause the server to reload the query from the cube. (Enter 0 to turn off Query Cache.) The operation of the query cache is dependent on the model/cube-level settings made in the model meta data. See Meta Data Library for more info.